【Route 53】名前解決先をEC2からTransfer Familyに引き継がせてみた

こんにちは、AWS事業本部コンサルティング部のこーへいです。

【前提】Transfer Familyには任意のホスト名を付与できる

上記記事にて解説するように、Transfer Familyには任意のホスト名を使用することができます。

特にDNSサービスでRoute 53を使用する場合、Transfer Family側の設定にてFQDNを登録するだけで、自動的にRoute 53にホストゾーンやCNAMEレコードを作成してくれるため導入が簡単です。

注意点としては例えばドメイン名にて「testkohei.link」を使用している場合、必ずホスト名を使用しなければならないため、Transfer Familyに登録するFQDNは「sftp.testkohei.link」等にする必要があります。

「testkohei.link」としてそのまま登録することはできません。

FQDNとは？ドメイン名・ホスト名・IPアドレスとの違い

既に使用しているFQDNをTransfer Family用に移行したい場合は？

今回、SFTP/SFTPサーバーをEC2からフルマネージドサービスであるTransfer Familyに移行したい要件がありました。

発生した問題

下記の様にSFTP/FTPSサーバーとして利用しているEC2宛のAレコードが登録されている状態で、Transfer Family宛のCNAMEレコードを登録する際はエラーが発生してしまいます。

この時、Transfer Family側の設定からRoute 53のCNAMEレコードを自動登録しようとすると下記のようにエラーが発生します。

以上より、Transfer Familyのコンソール画面よりホストドメインを設定するのではなく、Route53より手動でCNAMEレコードに変更する必要があります。

実際の手順

今回FQDNは「sftp.testkohei.link」を使用します。

1. CNAMEレコードに登録する値を確認する

コンソール画面より、 Transfer Family > 対象のサーバーを選択して、下記赤枠部分の値【{ServerId}.server.transfer.ap-northeast-1.amazonaws.com】をメモします。

2. Route 53から既存のAレコードをTransfer Family用のCNAMEレコードに変更する

コンソール画面より、 Route 53 > ホストゾーン > 対象のレコード選択 >【レコードを編集】を選択します。

レコードタイプをAレコードからCNAMEレコードに変更し、値にメモした【{ServerId}.server.transfer.ap-northeast-1.amazonaws.com】を貼り付けます。

【保存】を選択して更新完了です。

注意点

カスタムホスト名に関する注意点

今回は、Transfer Family側からではなくRoute 53より手動でレコードを設定したため、Transfer Family側の設定画面では下記のように赤枠のカスタムホスト名に設定が追加されていません。

Transfer Family側からカスタムホスト名を追加した場合は、下記のようにカスタムホスト名にFQDNが表示されこちらのリンクをクリックするとRoute 53に飛ぶことができます。

機能としての差異はござませんが、念のため把握しておくと良いでしょう。

【おまけ】Transfer Familyのカスタムホスト名に表示させたい場合

少々裏技チックですが、Transfer Family側にカスタムホスト名を表示しておいた方が管理として楽なので、そのような要望がある方向けの設定をご紹介いたします。

コンソール画面より、Transfer Family > 対象のサーバーを選択 > エンドポイントの詳細の「編集」を選択。

カスタムホスト名より、「その他のDNS」を選択する。
※ここで「Amazon Route 53 DNS エイリアス」を選択すると、発生した問題で紹介したエラーが発生します。

CNAMEレコードに登録したFQDNを入力して、「保存」を選択する。

設定画面に戻ると、カスタムホスト名が追加されています。

「その他のDNS」で登録した場合は、カスタムホスト名からRoute 53のリンクが表示されないですが、もし必要があれば設定してみてください。

SSHホスト鍵に関する注意点

名前解決先を変更したことで、今回の場合だと同じドメインから参照するサーバーがEC2からTransfer Familyに変わりました。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Please contact your system administrator.
Add correct host key in /Users/yoshikawa.kohei/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/yoshikawa.kohei/.ssh/known_hosts:6
Host key for <REDACTED> has changed and you have requested strict checking.
Host key verification failed.
Connection closed

その際に、SFTP接続を行うと上記のようなエラーが発生することがあります。

これはアクセス先のサーバーが変わったことで、偽物の悪意あるサーバーに誘導された可能性をユーザーに警告するエラーです。

この場合新しいアクセス先のSSHホスト鍵の情報をローカル側で更新する必要があります。

参考：「SSHホスト鍵が変わってるよ！」と怒られたときの対処

ダウンタイムについて

今回の検証では、AレコードからCNAMEレコードに直接変更するため新旧どちらのサービスにもアクセスできなくなるダウンタイムは瞬断程度でほぼほぼなかったです。

ただレコードに登録しているTTLの設定により、名前解決先が適用されるタイミングが変わります。

TTLが0以外の場合

先ほど変更前のAレコードのTTLは300秒と設定されていました(レコードは登録時、デフォルトでTTLが300秒にて設定されます)。

公式ドキュメントのTTL(秒)では、TTLについて下記の様に記述されています。

再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)

今回の場合Aレコードを変更したとしてもMAX300秒(5分間)程度はキャッシュによりEC2宛に名前解決が実施されます。

TTLが0の場合

AレコードのTTLが0秒に設定されている場合はキャッシュが適用されないため、レコードの変更がDNSサーバーに反映された直後からCNAMEレコードに名前解決が実施されるようになります。

注意点としてTTL(秒)に記載されているように、事前にAレコードのTTL設定300秒から0秒に変更しても、設定変更前のキャッシュが切れるまで(TTLが300秒に設定されている場合はMAX300秒程度)はTTLが0秒の設定は反映されません。

TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります

つまりレコードのTTL設定変更後は、300秒ほど待機したのちにレコードの最新情報が反映されているのをdigコマンド等で確認後、AレコードからCNAMEレコードへの変更作業を行うことを推奨します。

きちんとdigコマンドでAレコードのTTLが0秒になるのを確認しましょう。

終わりに

ダウンタイム自体はほとんどないものの、TTLの設定により実際に名前解決先の変更タイミングが変わることがわかりました。

実際にシステム切り替えを行う際は、事前に検証環境で検証を行い、本番環境での作業に適切な手法を採用することが大切と言えるでしょう